home *** CD-ROM | disk | FTP | other *** search
/ AMIGA PD 1 / AMIGA-PD-1.iso / NetBSD / docs-netbsd / Mailinglist-Archive / 1994-10.gz / 1994-10 / 000870_owner-current-users@netbsd.org_Mon Oct 31 00:46:17 1994.msg < prev    next >
Text File  |  1994-11-20  |  3KB  |  58 lines
  1. From: Alan Barrett <barrett@daisy.ee.und.ac.za>
  2. Subject: Re: gcc-ansi -pedantic and long long on NetBSD 
  3. To: "Chris G. Demetriou" <cgd@alpha.bostic.com>
  4. Cc: current-users@netbsd.org
  5. Mime-Version: 1.0
  6. Content-Type: TEXT/PLAIN; charset=US-ASCII
  7. Sender: owner-current-users@netbsd.org
  8.  
  9. On Sun, 30 Oct 1994, Chris G. Demetriou wrote:
  10. > i'm aware of all of these things.
  11.  
  12. I would have been surprised if you were not; I just wanted to give some
  13. background for this:
  14.  
  15. > > Apart from a possible desire to support broken code that assumes ints and
  16. > > longs are each 32 bits, I see no reason why a C implementation that
  17. > > desires to support 64-bit integers should not use 64-bit longs and 32-bit
  18. > > ints.
  19.  
  20. > HOWEVER, the problem is that ANSI C give you no way of specifying
  21. > explicit-length data types.
  22. > 
  23. > file offsets are 64 bits.  how do you specify that (using an integral
  24. > type) in ANSI C, without forcing 'long' to be 64 bits on 32-bit
  25. > machines?
  26.  
  27. Let me do some thinking aloud.  You probably know all this too, but
  28. I do make an interesting suggestion near the end...
  29.  
  30. I believe that off_t is required to be an integral type, so you can't
  31. play games with structures.  If you want off_t to be 64 bits, then you
  32. need a 64-bit integral type.  If you want to be strictly compatible
  33. with the ANSI C standard, the only integral types available are (signed
  34. or unsigned) char, short, int and long.  You probably want ints to be
  35. narrower than 64 bits, so you are pretty much forced into making long a
  36. 64-bit type.  I think that that would be OK.
  37.  
  38. If you don't care that much about strict ANSI C compatibility, then you
  39. can make longs narrower than 64 bits, and invent a new, non-standard,
  40. integral type of exactly 64 bits.  I think that that is OK too, and that's
  41. what has been done with "long long".  However, we now get complaints from
  42. the compiler in -ansi -pedantic mode about the use of the non-standard
  43. "long long" type. 
  44.  
  45. If you dont like the compiler complaints, there are a few obvious
  46. solutions:  Use 64-bit longs instead of inventing a non-standard 64-bit
  47. type; or make the compiler believe that "long long" is a standard type;
  48. or learn to live with the complaints although you don't like them; or
  49. add a new compiler option to stop all complaints about "long long".
  50.  
  51. There is also a less obvious solution:  Add a compiler option to stop
  52. complaining about the use of "long long" in system include files, or
  53. where it results from the use of a typedef that was defined in a system
  54. include file (but to continue to complain about use of "long long"
  55. elsewhere).  Perhaps even make such suppression of warnings the default,
  56. with an option to turn the warnings on.
  57.  
  58. --apb (Alan Barrett)